• chore(kitchen-sink): configurable endpoint #4766 : 3 dependent PRs (#4754 , #4777 , #4778 )
• refactor(rivetkit-core): rename StopReason to ShutdownKind and kill enum fallthroughs #4765
• chore(envoy-client): log command and event payloads #4751
• fix(rivetkit): minor sleep-cleanup follow-ups #4761
• docs(rivetkit): clean up stale setPreventSleep references in docs and JSDoc #4760
• docs(rivetkit): document keepAwake/waitUntil counter-arm race and surface bridge errors #4759
• test(engine): force overdue branch in alarm-during-sleep test with negative offset #4758
• fix(rivetkit-core): return stopping not starting when sleep/destroy called mid-shutdown #4757
• test(rivetkit): remove sleepWithPreventSleep fixture and tests #4756
• test(engine): add regression test for alarm-during-sleep-transition race #4755
• test(rivetkit-core): cover sleep/destroy guards and prevent_sleep no-op #4750
• docs: add keepAwake vs waitUntil table and internal sleep-sequence invariants #4749
• feat(rivetkit): expose c.keepAwake(promise) through native path #4748
• refactor(rivetkit): deprecate setPreventSleep to no-op in TypeScript #4747
• fix(rivetkit-core): enumerate non-drained counters in grace deadline warn log #4746
• fix(rivetkit-core): abort graceful cleanup task when grace deadline elapses #4745
• fix(rivetkit-core): error on sleep/destroy before startup or already-requested #4743
• fix(rivetkit-core): cap SerializeState shutdown timeout at 15s #4742 👈 (View in Graphite)
• refactor(rivetkit-core): remove prevent_sleep field and deprecate set_prevent_sleep to no-op #4741
• fix(api-public): remove orphan import_export actors module #4764
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Code Review: fix(rivetkit-core): cap SerializeState shutdown timeout at 15s

Overview

This is a minimal, focused change that reduces the SERIALIZE_STATE_SHUTDOWN_SANITY_CAP constant in rivetkit-rust/packages/rivetkit-core/src/actor/task.rs from 30 seconds to 15 seconds. This constant caps the maximum time the actor shutdown path will wait for a SerializeState reply before giving up and proceeding with an empty delta set.

Analysis

Correctness

The constant is used in save_final_state() as a deadline on the reply_rx oneshot receiver for a SerializeState { reason: Save } event sent during shutdown. Reducing from 30s to 15s is a conservative and reasonable cap — 15s is still generous for a serialization callback, and a faster cap means actors fail-faster on a hung user serializeState callback instead of blocking the shutdown pipeline for half a minute.

The timeout arm returns Vec::new() (empty deltas) and logs an error, which means a timed-out serialization still proceeds to save_state rather than hard-failing. The behavior on timeout is unchanged; only the wait window narrows.

Code Quality

• The change is exactly what the title describes: one-line, one constant, no collateral drift.
• The constant name (SANITY_CAP) correctly signals this is a guard against pathological slowness, not a configured SLA.

Concerns / Suggestions

• Missing rationale in PR description. The PR template is unfilled. It would be helpful to know what motivated the reduction (e.g., observed shutdown hangs in production, a new shutdown-pipeline deadline that this must fit within, alignment with a documented timeout budget). Without that context it is hard to verify the value is correct vs. arbitrary.
• No corresponding doc/limit update. Per .claude/reference/docs-sync.md, changes to actor timeouts should be reflected in website/src/content/docs/actors/limits.mdx. If this timeout is user-visible or documented, that file should be updated.
• Consider making this configurable. If actor serializeState callbacks legitimately vary in cost (e.g., large in-memory state), 15s could be too tight for some workloads. An ActorConfig field (with 15s default) would allow tuning without a code change. That said, this is a sanity cap rather than a normal-operation limit, so a hardcoded constant is defensible.
• Test coverage gap. There are no new or updated tests verifying behavior at the boundary (e.g., that a hung callback times out at ~15s and proceeds with empty deltas). If this was prompted by a real regression, a test that reproduces the scenario would be valuable.

Overall

The change is safe and well-scoped. The main gap is the empty PR description — the motivation and any related incidents should be documented so future maintainers understand why 15s was chosen over 30s (or any other value).